我相信，好的体系总是是简单的，但是细节复杂而有序。
为什么不提倡 SCRUM
主题：失去天才
主题很明显，从开发的角度说，Scrum是毫无人性的。它默认每个人能力都是一样，水平也是一样的，产出水平也是一样的。并且在极力抹平个体差距。最差劲的是它把人当做是机器；从管理者角度说，他是员工出错的屏障，“有bug？”“扔进bug池就行了。”。也是功能不按期完成的借口，”新任务？““你看这是我们的用户故事，排在三个月之后吧。”；从领导的角度来说，交付的东西很模糊并不具体，比如故事地图。如果说是看一眼的领导还好，但是要刨根问底呢？有谁能回答的面面俱到。最重要的是，用户故事会成为一个屏障。
当然写这一切的问题也比不上人才流失，特别是天才的流失。因为这种敏捷方案，强调团队，但是不突出个人。有时候做事很好的人，（这个行业更多做事多，但是不说话的）会因为公司政治而离开，会因为团队不理解而离开，更会因为一直表现平平而心情失落离开。我清楚的是市面上的实际情况是能力参差不齐。个人开发要盘算到团队上算绩效。这都是不公平的现象。最终的结果可能就是能力稍高的人不堪重负离开了。
为什么做不好 DEVOPS
主题：自动化
开发运维，我理解意思就是让开发学着运维的活，节省成本。最重要的是开发部署运维表现起来很流畅。但是对人的要求也高很多。所以在执行的时候很多做不到完全的，仅仅是必要的时候还需要运维帮忙。在我看来，自动化是解决这一问题的终极方案，特别是后来出现的 AIDEVOPS。但是要好好的建立起数学模型才可以。那在这之前，脚本自动化其实是简单可行的一种方案。能够让开发有运维的能力。
OKR？ 简单点好伐
主题：待办事项列表更简单
缺点：没有细节，缺少全局思想（事情在传递的时候很容易跑偏）
OKR，听起来真的高大上，执行的时候做法上就像是一个由上而下的待办事项列表。一级一级分的很清楚。有时候做的不好，可能级别之间的代办事项会出入很大。这点不好控制毕竟人各有理解方式。所以想到由上而下齐心去做好一个代办列表还真的不是那么容易的。其实根本没减少多少任务。而且没有细节，不好评审。最多也是百分之多少完成度。让人难以想象究竟做了什么。
所以为了解决上边的这些问题，结合自己的经验。我觉得，量化的过程是一个自然发生的事情，这样就可以避免不合适团队的侵入式，让人反感。底薪加奖金的工作方式，至今还没有在IT领域里发生过，究其原因主要是量化不好做，奖金的数量不好确定。但是为了公平起见，也为了更好的做开源项目，我想这是最好的方式。